IT systems are a complex interplay of a multiple service components, resources, users of IT services, and service and site specific policies. An IT service component may depend on one or more other service components and resources, and it may provide support to one or more other service components. The component also may directly support user requests and demands. Because these are dynamic systems, changes need to be made from time to time; e.g., upgrades, fixes, and so on. Making a change affects the availability of the IT service component being changed, and affects the availability of other IT service components that depend on the component being changed.
The time interval when the change is being applied is of interest to the direct users of a component as well as to the users of components that depend on the component being changed. In addition, such change also brings uncertainty about the availability or reliability of a service after the change is applied. For these reasons, the making of a change to any IT component requires consent from the users of that component as well as from the users of the components that depend on the component being changed. In addition, policies are put in place for streamlining such changes.
In an IT ecosystem, approvers are designated to represent the interests of various user groups and IT service components that form the fabric of an IT system. An approver is responsible for approving two aspects of a change request:                (i) the actual change to be implemented, and        (ii) the time when the change is to be applied.        
An approver is required to take into account the interests of the users or of the service component the approver represents. An approver also may be responsible for policy enforcement in applying a change.
Throughout this specification, the time window when a change is to be applied will be referred to as the change schedule.
As mentioned earlier, a change affects the availability of the component being changed as well as the components that are dependent on the component being changed. Thus, in determining a change schedule, there is a tension between the availability demands on a component and the importance or the urgency of the change being applied. The larger the number of components affected by a change, higher is the number of constraints to the problem of determining an all-agreeable change schedule. In many cases, a change to a lower level IT service component such as OS platform, can affect ten or more other IT service components and user groups. Finding a common change schedule agreeable to all involved parties is a challenging problem.
Today this problem typically is handled manually by proposing a change schedule and asking the approvers to approve or disapprove the change schedule. Even if the schedule is unacceptable to one of the approvers, the process is repeated with another change schedule. Thus, scheduling a required change itself can take an indeterminate amount of time and may waste valuable time before an urgent change to the system can be made. Underneath this inefficiency there are two fundamental problems:                (i) the proposed change schedules are determined by guesswork rather than by taking into account the available information on the constraints and priorities of the individual approvers and by deducing an acceptable change schedule intelligently based on the available information        (ii) relative impact of the change on the individual approver's domain is not considered and thus, priorities of all approvers are considered equal. This can result in unnecessary delays and deadlocks in scheduling.        